System Center Configuration Manager 2007 : Hierarchy Planning

About Sites

Configuration Manager clients receive their policy from their assigned site. Within a site, client agents and other components share a common configuration. As an example, Remote Tools options are enabled on a per-site basis. The site therefore defines a natural administrative boundary for those clients that share configuration options and should be managed together.

Sites also align with geographic and network boundaries. Communications within a site require a high level of network services, whereas communications between sites can take advantage of scheduling, compression, and other optimizations for remote communications. 

Site Codes

Each Configuration Manager site is identified by a unique three-character site code. Site codes can consist of upper- and lowercase letters and/or numeric digits. Be aware of the following restrictions when using site codes:

• Avoid using reserved names such as AUX, CON, NUL, PRN (see http://msdn.microsoft.com/en-us/library/aa365247.aspx for the list of reserved filenames), or SMS when choosing site codes.

• Avoid reusing site codes previously used in your Configuration Manager hierarchy. Site codes are stored in the site databases of other sites in the hierarchy and in some configurations are saved in Active Directory and WINS. If you were to reuse a site code, it is possible that all references to the old site were not removed completely or are reintroduced from a restored backup. This could cause problems resolving the site.

Designing a Hierarchy

The site at the top of your hierarchy is the central site. In some cases, this may be the only site you need. Most large or geographically dispersed organizations will benefit from having additional sites. A simple hierarchy example is shown in Figure 1. This figure shows part of a proposed hierarchy design for the domain used in this book, SCCMUnleashed.com. Not all sites in that domain are shown in Figure 1, and some sites may be combined in the final design.

Figure 1. A possible three-tiered hierarchy for SCCMUnleashed.com sites in Europe and the Asia/Pacific (APAC) region

You may want to consider additional sites in the following instances:

• Locations are separated from other existing or planned sites by wide area network (WAN) links— Generally, a site should be within a well-connected region, such as a local area network (LAN) environment. To avoid managing an unnecessarily large number of sites, locations with small numbers of computers should generally be part of the existing site with the best connectivity.

• Groups of machines require different client agent settings— You will want to create a separate site for machines requiring different client agent settings, because client agent settings are configured on a per-site basis. It is possible to override sitewide settings on individual clients using local policy; however, this is not generally recommended because it makes troubleshooting more difficult.

• Support is required for down-level clients— If sites are in native mode, you may need a separate mixed mode site to support older clients, such as SMS 2003 Service Pack (SP) 3 clients. 

• Multilingual requirements— Locations that will be using different language versions of the Configuration Manager client and server software should generally be separate sites.

• Scalability considerations— Regardless of other considerations, very large organizations will need multiple sites for scalability reasons. The maximum number of clients supported by a single site is 100,000.

The best practice for multisite hierarchies is to have a central site with no clients other than the site server itself. All sites other than the central site are joined to a parent site. Each site may have only one parent site but may have more than one child site.

Primary Sites Versus Secondary Sites

ConfigMgr 2007 can incorporate primary and secondary sites in a hierarchy. A primary site is a site with its own SQL Server database. Primary sites can have secondary sites or other primary sites as child sites. Configuration Manager clients are assigned to primary sites, and they receive policy from their assigned sites. Secondary sites are used at remote locations to provide Configuration Manager services locally to clients assigned to primary sites in the hierarchy. Secondary sites cannot have child sites and they do not have clients assigned to them. Secondary sites are administered from their parent site.

You may decide to add primary sites for the following reasons:

• Administrative advantages— Each client is assigned to a primary site. Clients receive policies, including client agent settings, from their assigned site. If your clients need different client agent settings than those at the parent site, you may choose to deploy an additional primary site. Secondary sites are administered though their parent site. Delegating administrative privilege to local personnel, such as the ability to distribute software at the site, is simpler at a primary site than a secondary site.

• Hierarchy advantages— You can disjoin a primary site from its parent site and join it to a different site, but you must reinstall a secondary site to move it in the hierarchy. This is important if your organizational structure frequently changes due to office closures and relocations, mergers and divestitures, and so forth. A primary site can also have child sites; secondary sites cannot.

• Scalability advantages— With proper design, a primary site can support over 100,000 clients. A secondary site can support around 1,000 clients.

You may decide to use a secondary site based on the following considerations:

• No need to install and support SQL Server— Primary sites require access to Microsoft SQL Server to access the ConfigMgr database. Unless you already have a SQL Server installation at a primary site, you will need to install SQL Server either on the site server or on a separate server. In either case, this will require additional hardware resources and support efforts.

• Licensing costs— Currently, secondary sites do not require a Configuration Manager 2007 server license or a SQL Server license. Of course, all site systems require a Windows Server license. 

Planning Your Hierarchy Structure

A consistent principle in Configuration Manager is that a parent site must be at least as advanced in its software version and configuration as its child sites. This is true in terms of both code version and security mode. As an example, a Configuration Manager 2007 SP 1 site can have a child site without SP 1, but could not report to a parent site without SP 1. A Configuration Manager site can have SMS 2003 SP 2 or higher child sites, but cannot have an SMS 2003 parent site. Similarly, a native mode site can have a mixed mode child site, but not vice versa. Figure 2 shows some possible parent/child relationships that are allowed and others that are not allowed.

Figure 2. Examples of parent/child relationships that are allowed and others that are not allowed

You should plan your hierarchy such that upgrades, service packs, and other enhancements can be easily applied, starting from the central site and then proceeding down the hierarchy. You should also consider capacity, bandwidth, and latency issues when deciding how to structure your hierarchy. Figure 3 shows an alternate hierarchy for the same sites previously shown in Figure 1.

Figure 3. A possible two-tiered hierarchy for SCCMUnleashed.com sites in Europe and the APAC region

The flatter hierarchy displayed in Figure 6.3 has the following advantages:

• Less processing and storage capacity is required in the Beijing (BEJ) and Brussels (BXL) primary sites. With the original hierarchy design, these sites have to process communications and store data from their child sites as well as from local clients.

• Network communications between the central site and the Amsterdam (AMS), Katmandu (KAT), and Mumbai (MUM) sites as configured in Figure 6 will introduce additional latency because of the need to send data through an intermediate site. This is particularly true if sender scheduling limits the hours for sending certain data.

• Overall bandwidth consumption may be lower because communications between the central site and the AMS, KAT, and MUM sites can take the optimum network route, rather than necessarily going through the intermediate primary site. As an example, if your sites are connected through a Multi Protocol Label Switching (MPLS) cloud, traffic between a site and its direct child site requires one trip through the cloud, whereas an intermediate site will store and forward data, which requires an additional trip.

• The impact of a site or communications failure affecting the BEJ or BXL site is limited to that site. Site recovery at those sites will be considerably simpler in this model.

• Future restructuring may be easier. As an example, if Beijing were part of a divestiture or office closing, the Katmandu site would not need to be reinstalled in the flat hierarchy model.

• Legal requirements such as export controls may prohibit certain software or data from traversing certain intermediate sites.

The more structured design in Figure 1 also has some advantages:

• Software packages, software updates, and operating system images can be distributed using a fan-out mechanism, which reduces the workload of the initiating site and the network link between the initiating site and other sites. For example, a package needed at the BEJ, KAT, and MUM sites can be copied once across the link from the central site to Beijing, and then copied from Beijing to Katmandu and Mumbai. This example uses a central site in North America, and Beijing, Katmandu, and Mumbai are in the Asia/Pacific region. This is an important consideration because the WAN links from the central site to the APAC sites have less available bandwidth than the connections within the APAC region.

• Administrators in the APAC region can connect to the BEJ site to administer the KAT secondary site rather than needing to connect to the central site. Similarly, administrators in Europe can administer the AMS secondary site through BXL. Although a relatively flat hierarchy is generally recommended, it may make sense to introduce additional layers into the hierarchy if several sites are in a region that is remote from your central site.

Using SMSMap to Document Your Hierarchy

SMSMap (described at http://technet.microsoft.com/en-us/magazine/cc137998.aspx) is a freeware utility you can use to automatically generate Visio drawings of ConfigMgr 2007 and SMS 2003 sites and site servers. You can run SMSMap from any machine with Microsoft Visio installed. Here are some key points:

• As shown in Figure 4, you can enter credentials for an account with at least read access to your Configuration Manager site database and connect to any primary site server.

  Figure 4. The SMSMap utility Connection tab

  

• To map your entire hierarchy, connect to the central site. The utility gives you a choice of six layout designs; the Options tab, shown in Figure 5, allows you to specify the level of site detail to gather. The program will automatically generate a map showing your site servers and the other details you specify. Once you save the drawing, you can edit it in Visio to suit your preferences.

  Figure 5. The SMSMap utility Options tab

  

Jeff Tondt, a Senior Consultant for Microsoft Consulting Services, developed SMSMap, which is available at http://www.tondtware.com/downloads.html. Microsoft TechNet magazine took an in-depth look at this valuable utility in July 2007 (http://technet.microsoft.com/en-us/magazine/cc137998.aspx). Several enhancements have been added since that article was written, including support for Configuration Manager.